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TECHNICAL MEMORANDUM 


A STRATEGY FOR INTEGRATING A LARGE FINITE ELEMENT MODEL 
USING MSC NASTRAN/PATRAN: X-33 LESSONS LEARNED 


1. INTRODUCTION 


The responsibility for large structures rarely rests in the hands of a single institution any longer. 
The responsibility is now being spread across a larger number of industry partners. So too is the respon- 
sibility for the structural finite element models used for assessing these structures. This broad effort 
often needs to be refocused into an integrated model that reflects characteristics of the full system. 

This is the task of the model integrator. 

Attempts have been made in the past to provide tools to the model integrator to simplify this 
task. ALAS * is an example of a tool that attempted to simplify some of the analytical aspects of the 
integration task. Many of today’s computer-aided engineering (CAE) packages have various tools and 
degrees of success supporting this process. MSC/SuperModel is one of the latest tools to put forth a 
system for simplifying this process. 2 - 3 It itself is based on tools developed in-house at the old 
McDonnell-Douglas Aircraft Corporation similar to in-house tools developed at many companies. 

Even with these current and developing tools most of the modelers involved in the project likely use 
different CAE packages. This offers its own challenges to the integrator. 

For the past 3 years the Structural Dynamics and Loads Branch of NASA’s Marshall Space 
Flight Center (MSFC) has had the task of integrating the X-33 vehicle structural Finite element model. 
In that time, five versions of the integrated vehicle model have been produced. A great number of 
lessons were learned in this process. Presented here is a strategy that, if used at the outset of the project, 
will pave the way for a smooth integration. This strategy would benefit anyone given the task of inte- 
grating structural finite element models that have been generated by various modelers and companies. 
This strategy also provides benefits regardless of the tools used to help the integrator in this task. 



2. THE X-33 MODEL INTEGRATION PROBLEM 


The X— 33 vehicle is an advanced technology demonstrator sponsored by NASA. The X-33 
program will demonstrate, in flight, the new technologies needed for a reusable launch vehicle using a 
half-scale prototype. NASA has selected Lockheed-Martin Skunkworks to design, build, and fly the 
X-33 test vehicle. The industry team, with Lockheed-Martin Skunkworks as lead, includes Lockheed- 
Martin Michoud, B.F. Goodrich (previously Rohr), Boeing Rocketdyne, and NASA. 

The X-33 has a complicated and highly coupled structural design (see fig. 1). It consists of a 
liquid oxygen (lox) tank sitting on top of a pair of side-by-side liquid hydrogen (LH 2 ) tanks. Behind 
and in-between the hydrogen tanks are the two aerospike engines. Over all of this is a complex 
aeroshell structure that provides thermal protection and the aerodynamic shape of the lifting body. The 
canted and vertical fins and body flaps are also attached to the thrust structure. 

In order to assess the design, an integrated vehicle finite element model was required to deter- 
mine internal loads. These internal loads were derived from externally applied forces in both static and 
transient dynamic loads analyses. The required model was generated from individual major structure 
models obtained from across the industry team. Models of the LH 2 tanks, thrust structure, intertank, 
and landing gears were provided by Lockheed-Martin Skunkworks. The lox tank model was provided 
by Lockheed-Martin Michoud. The aerospike engine model was provided by Boeing Rocketdyne. B.F. 
Goodrich provided models of the canted Fin control surfaces. The Structural Dynamics and Loads 
Branch of NASA’s MSFC had the task of modeling the aeroshell, body flap control surfaces, canted 
and vertical fins, and the rotating launch mount. The Structural Dynamics and Loads Branch also had 
the task of integrating the various models into the full vehicle model. 


The integrated vehicle model that resulted has had five versions. Four complete loads analysis 
cycles have been completed. These include static prelaunch, ascent, descent, landing, and transient 
liftoff analyses. A fifth loads cycle is underway. The models have also been used to assess dynamic 
characteristics for flight control analyses. The model grid count peaked at 29,427 grids for load cycle 4 
and is now down to 20,400 grids for load cycle 5 after a concerted effort to reduce the model size. 




Figure 1. Cut-away view of X-33 structural finite element model. 
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3. STRATEGY FOR MODEL INTEGRATION 


The strategy presented here consists of six decisions that need to be made at the outset of the 
project. These decisions, once made and agreed to by the modeling team, will pave the way for a smooth 
model integration. These six decisions are: purpose of model, units, common material list, model num- 
bering, interface control, and archive format. Each is discussed in detail below. 

3.1 Purpose of Model 

The first decision to be made is the purpose of the model. Is it a stress model? Is it a loads 
model? A dynamics model? This decision drives many of the following decisions. In particular, it 
defines the scope of the model and therefore the approach to the modeling. It would also have a direct 
impact on the size of the model. The effort for X-33 was to develop a model that would be used to 
recover internal element forces for use by stress analysts. It was never intended to recover stresses, as 
this would have led to a model that would be all but impossible to run. It was also meant to adequately 
represent elastic modes from 0 to =25 Hz so that liftoff transient loads could be recovered. These 
dynamic characteristics were also to be used for control stability studies and POGO analyses. During 
the entire development of the model it was a continual challenge to balance the need for accurate forces 
(not stresses) and dynamics and still have a reasonably sized model. Accommodations also had to be 
made, both in increased and decreased fidelity, when it was decided the model would also be used for 
flutter analyses. 

It should be noted here that on the X-33 project two model “styles” existed. One style of model- 
ing consisted of modeling the structure the way it was intended to work; i.e., modeling web caps with 
rod elements because they were primarily intended to carry axial load. The other style modeled the 
structure the way it was drawn or built in order to verify the assumptions used in design. For example, 
the web caps were modeled with bar elements to verify that the axial load was the only significant load. 
Every modeler uses a combination of these styles. The reasons include preference, economy, time, and 
maturity of design. There is little expectation that the modeling can be controlled to the point of requir- 
ing a consistent style. However, the model integrator needs to be aware of these styles so that any issues 
that come up because of them can be quickly recognized and settled. 

3.2 Units 

The units of measure the model will use need to be decided. This could be of great importance if 
the model is a joint venture between European and U.S. modelers. Even if the standard units used by the 
modelers are similar, care should be taken, especially with mass versus weight units. While in the U.S. 
most aircraft modelers commonly using inches, density poses a problem. Many modelers use weight 
density but also, many modelers use mass density. The desired units for the integrated model should be 
decided very early so the individual modelers can accommodate this. This was not done on the X-33, so 
a number of models had to have their densities converted. Fortunately, all models were in inches. 


;i rr 
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3.3 Common Materials List 


The next thing to determine is material properties. It would be very advantageous to establish a 
common materials list for use by all the modelers. The advantage would be a consistent set of properties 
between modelers and therefore no redundancy in material definitions. Even though the materials might 
be standard, there are many variations in alloys and thermal characteristics. This list would obviously 
grow and change as the design evolves, but it should be a simple matter to provide regular updates. Even 
if a particular model needed some specialized properties, it would start with a common base. 

In conjunction with the common materials list, the ambient temperature of each model should be 
defined. This could have a large effect on the material properties used for that model. For example, 
composite material properties are much more dependent on temperature than metals, but even aluminum 
has significant changes at cryogenic temperatures, such as the lox tank for the X— 33. Also thermal 
protection materials drastically change properties over their expected temperature ranges. Several 
different material definitions may be necessary for the same material because of its use in different 
areas. For example, a composite material may be used in a cryogenic LH 2 tank and also a hot thermal 
protection support beam and therefore have two different material definitions. A common reference 
temperature and units for coefficients of thermal expansion should also be established to facilitate a 
thermal contraction or expansion assessment. 

The use of a common materials list would also allow for easier changing of material properties 
for assessment of different temperature profiles of the integrated model. For example, the ascent tem- 
perature profile of the X-33, and therefore its material properties, may be drastically different from the 
descent profile. You may therefore have a different common materials list for each temperature profile 
with the same material identification. These lists could then be exchanged to assess the model for the 
different profiles. 

Invariably, somewhere, the model will use a “stiff’ bar or plate where an RBAR won't do or use 
stiff springs to recover interface loads in the global coordinate system. It would be good to define these 
materials and properties in the common materials list also, so all the modelers could be consistent and 
reduce redundant definitions. 

The value of the MSC/NASTRAN parameter K6ROT for drilling stiffness in shell elements 
should be decided early. Some modelers depend on a large value of K6ROT to alleviate drilling stiffness 
problems. Others depend on zero or low values of K6ROT to allow some freedom in this direction. Even 
if you can specify different K6ROT parameters for different NASTRAN superelements, it is a good idea 
to specify a default value so the modelers may accommodate it with other techniques. 

Neither the common materials list or temperature profiles were established for the X-33 model, 
and this has caused a certain amount of aggravation throughout its evolution. Such a list would also be 
of great benefit to model correlation efforts at a later date. It may still be necessary to go back and 
establish this list, but it would have been much easier to have established it from the start. 
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3.4 Model Numbering 


Assigning node number ranges to the different models is fairly common practice. You may want 
to specify a target number of grids to help limit the size of the model, but be sure to allow adequate 
room for inevitable growth. Enforce the numbering not only on nodes but also elements, properties, rigid 
elements, and multipoint constraints (MPC’s). Rigid elements and MPC’s can cause difficulties. MSC/ 
NASTRAN and MSC/PATRAN sometimes treat them as elements and sometimes treat them as separate 
entities. This can particularly be a problem if you later decide to use superelements. Older versions of 
MSC/NASTRAN would allow an element and a rigid element to have the same number in a standard 
analysis but not in a superelement analysis. To be safe, make sure their numbering is exclusive of the 
elements. The material numbering should be from the common materials list but if a special material is 
needed, enforce the numbering range. And finally, make the ranges different enough so that you can 
easily identify the model that an element, node, or property belongs to. 

3.5 Interface Control 

If at all possible, an Interface Control Document (ICD) should be established for the different 
model pieces. This is a document that defines the interface geometry and loads between different por- 
tions of the model or structure. For the most part, these data are already contained in structural ICD’s. 

For the X-33, this was true for interfaces between companies such as B.F. Goodrich and Lockheed- 
Martin Skunkworks or Lockheed-Martin Michoud and Lockheed-Martin Skunkworks. Lockheed-Martin 
Michoud’s ICD (fig. 2) was particularly well done and was invaluable in interfacing the lox tank model 
with other models. Much of the X-33 was designed within the same company and did not have a struc- 
tural ICD. It would be very beneficial to establish such ICD’s for the purpose of the models, even if they 
are not rigidly controlled documents. They might also help define better divisions of responsibility for 
the model pieces. An example for the X-33 would be the aeroshell ring frames over the LH ? tanks. The 
ring frames’ modeling responsibility belonged to the aeroshell modeler and the tank modeling responsi- 
bility to another. Since the ring frames attached continuously to the tanks, a great deal of coordination 
was required to make the model meshes match. A better approach might have been to let the tank mod- 
eler model the ring frames and define an ICD for the frame to aeroshell interface. This would still 
require coordination, but the interface would be better defined and more along structural lines rather 
than model meshes. 

In instances where the interface between structures should only pass loads or allow compliance 
in certain directions, the ICD should carefully indicate which side these releases are modeled. The 
structural ICD should make this clear; however, many modelers that are only concerned with one side of 
the interface will not make any provisions for special releases except through model constraints. These 
constraints are then lost upon integration and it is left to the integrator to fix the problem, usually with 
springs or rigid elements. This is not necessarily the most efficient method. This problem occurred 
regularly on the X-33 project. 



Figure 2. Sample from Lockheed-Martin Michoud’s ICD 1 . 


3.6 Archive Format 

The format for storing and transmitting the model data needs to be decided. For the X-33, this 
was decided to be the MSC/NASTRAN bulk data. This decision was made for two primary reasons. 
First, because the modeling effort spanned several companies that used various CAE packages, even 
different versions of those packages, the bulk data was deemed the most portable. MSC/NASTRAN 
was the most common denominator. Second, even though the CAE translators to MSC/NASTRAN are 
continually improving, they are not perfect. Since these models would be passed back and forth many 
times and passed through CAE translators multiple times, it was decided that the bulk data would be the 
trusted copy. Any modifications that were made with the help of the CAE packages would be output to 
MSC/NASTRAN but then text edited into the archive bulk data format. In fact, for X-33, most errors 
between model versions were traced back to passes through the CAE packages where beam orientations, 
section properties, and material definitions were compromised. Bulk data comments could also be 
preserved with this cut-and-paste method. 

For X-33, it was also decided that the separate models would remain in separate files and 
assembled using “include” statements in the MSC/NASTRAN analysis File. This provided ease of 
updates for portions of the model that were in various stages of flux and design. A submodel’s included 
bulk data file could easily be replaced with a new one as updates were made without affecting the rest 
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of the model. Also, had the common materials list been used, this would be a convenient way of using it. 
This decision, as beneficial as it was, created one problem — MSC/NASTRAN does not allow duplicate 
grid definitions. This prohibited having grid definitions in both bulk data files for models that interfaced. 
However, the CAE packages cannot read in the bulk data for a submodel without this grid definition. 

For example, SDRC IDEAS would not read in any of the file if there was such an error, while MSC/ 
PATRAN would not read in affected elements but would read the rest of the file. 

One suggestion for handling this problem was that each submodel have completely unique grid 
numbers and then have an additional interface file that contained connecting springs or rigid elements. 
This could be an effective method for a relatively simple model with few interfaces, but for this highly 
coupled structure, the cost of additional grids and elements would be prohibitive. Also, it would be very 
difficult to ensure absolutely coincident grid points that are required for this method to work correctly. 

The solution decided on for the X-33 was that within a submodel bulk data file all grid defini- 
tions that interfaced with other submodels would be placed in the bottom of the bulk data file where 
they could be easily found (fig. 3). Further, the bulk data files would be considered in an upstream/ 
downstream fashion similar to superelements. The submodel bulk data files were named with a preced- 
ing number to facilitate this upstream/downstream ordering. An interface grid was defined once in an 
upstream bulk data file. When it was referenced in a downstream bulk data file, its definition would be 
commented out with a unique integration comment such as “$INTEG Thus, when all bulk data files 
were included in the MSC/NASTRAN analysis file, no duplicate grid definitions would result. If it was 
necessary to read a bulk data file into a CAE package or have a checkout analysis done by itself, then all 
occurrences of the “$INTEG $” comment would be changed to nothing in a text editor first. 


4. USE OF MSC/PATRAN IN MODEL INTEGRATION 


MSC/PATRAN was the CAE package used for the model integration. This was a difficult task 
made relativly easy by several of MSC/PATRAN’s features associated with creating and displaying 
groups. Lockheed-Martin Michoud reported great difficulty completing similar tasks with SDRC 
IDEAS. In particular, MSC/PATRAN offered a unique benefit to this integration process. With the 
submodel bulk data files defined as they were, they could be read into MSC/PATRAN to form an inte- 
grated model database, as long as the files were read in the proper order. This could be done without 
having to edit out the “SINTEG $” comments. In addition, this process was vastly aided by the use of a 
journal file. The journal file was constructed to create a group, set it as default, and then read the bulk 
data and repeat for the next file. With this journal file it was extremely easy to reconstruct integrated 
model databases for viewing results. It was also very easy to establish an X-33 template for use by other 
engineers. For the other companies that used MSC/PATRAN, but had different versions on different 
machines, this was a convenient way of providing them with a database. 
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Figure 3. Sample of bottom portion of a submodel bulk data file 




5. PITFALLS ENCOUNTERED WITH MSC/PATRAN 


The largest MSC/PATRAN pitfall encountered lies in the association in the database of the beam 
orientation vectors with the property rather than the element. The X-33 model has a large number of 
beam elements with the same cross-sectional properties but different orientations. The orientations were 
not easily defined by an MSC/PATRAN field, so a different property was required for each while defining 
them in the database. These were later text edited in the bulk data file to reference the same property card. 
On reading this bulk data file back into MSC/PATRAN, the property remained a single property entry 
with a MSC/PATRAN spreadsheet field for the orientation. This was convenient when checking beam 
properties. However, when it was desired to add a new beam based on the existing property, the output 
beam orientation was undefined and had to be text edited later in the bulk data file. 

Another pitfall was described in section 3.5, regarding translation between the CAE package and 
the bulk data. Even MSC/PATRAN and MSC/NASTRAN had this problem, although it was worse with 
other CAE packages. In fact, for the X-33, most errors between model versions were traced back to 
passes through the CAE packages where beam orientations, section properties, and material definitions 
were compromised. 

One other pitfall occured regarding the translating of the bulk data into MSC/PATRAN. This 
problem came with the switch from MSC/PATRAN 6.2 to MSC/PATRAN 7.0. The model contained a set 
of MPC’s that were defined on multiple MPC cards but had the same MPC number. MSC/NASTRAN 
handles this very well. MSC/PATRAN reads each of the separate cards and then internally offsets the 
MPC identification for each one. This particular offset is not user controllable. In version 6.2 this offset is 
fixed at 1 , which caused no problem. In version 7.0 the fixed offset was changed to 10,000. This caused 
the offset numbers to clash with other rigid element entities. Fortunately, the journal file could be reor- 
dered somewhat to avoid this problem. 


6. CONCLUSION 


The task of integrating a structural finite element model that has been developed by several 
modelers from several companies is challenging. This task has unquestionably benefited from all the tools 
made available through the currently available CAE packages. There are, however, strategies that can be 
brought to bear that can smooth the process greatly. Even with many of these strategies now being in- 
cluded in the next generation of CAE packages, the model integrator’s understanding of them is essential. 
This is particulary true with the variety of sources of models being integrated. These strategies are best 
used early in the project to lay a good foundation for integration. A strategy has been presented here that 
consists of six decisions that need to be made: purpose of model, units, common materials list, model 
numbering, interface control, and archive format. This strategy has been proved and expanded from 
experience on the X-33 vehicle. 
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